fix: fail over unhealthy Daytona sandbox hosts - #183

## Why

Daytona currently reports an unhealthy sandbox host with a structured
HTTP 503 body but no provider error code. The sandbox lifecycle should
not depend on provider message text.

## What changed

- validate the Daytona error projection at the adapter boundary
- normalize the specific host-recovery response to an internal
`daytona_host_recovering` code
- make lifecycle classification depend only on the internal code and
HTTP status
- document the normalized adapter-to-lifecycle contract

This preserves the guarded same-volume runtime replacement behavior
merged in #183 while keeping provider response details isolated to the
Daytona adapter.

## Verification

- `pnpm lint`
- `pnpm typecheck`
- `pnpm turbo build --force`
- `pnpm deadcode`
- `pnpm architecture:check`
- `pnpm turbo skills:build`
- captured the live Daytona 503 response shape for the affected sandbox
without exposing credentials

Production behavior will be exercised after merge and exact-SHA
Cloudflare deployment.

## Summary

- Treat provider `length` finish reasons as nonterminal model turns.
- Checkpoint the partial response and continue durably with an internal
instruction to split interrupted operations into smaller complete tool
calls.
- Validate the SDK finish-reason contract at the agent boundary and
accept only `stop` as tool-free semantic completion.
- Fail blocked, provider-error, and invalid terminal reasons explicitly
instead of publishing incomplete work as successful.

## Root cause

The production Pomodoro retry recovered its Daytona runtime correctly,
but Claude reached its per-response output limit while forming the next
operation. The Workflow used only the absence of parsed tool calls as
its completion condition, so it finalized that truncated turn and
exposed the sandbox readiness page.

## Architecture

The Mastra adapter validates the six AI SDK finish reasons. Cloudflare
Workflow owns the policy: tool calls execute durably; `length` appends a
non-visible continuation message and starts another checkpointed model
turn; only `stop` completes a tool-free run. This keeps semantic
completion in charge without adding a step, token, duration, or cost
ceiling.

## Decisions

| Decision | Choice | Reason |
|---|---|---|
| Handle truncation in Workflow | Durable continuation | It preserves
replay safety and applies to every provider and run type. |
| Preserve partial response history | Append an internal user
continuation message | The next turn sees the exact work already
attempted and avoids repeating completed actions. |
| Keep provider output settings unchanged | No fixed output-token
override | A larger fixed cap only postpones truncation and does not
establish correct completion semantics. |
| Reject non-stop terminal reasons | Explicit upstream failure | Content
filtering and provider errors are not successful outcomes. |

## Production evidence

- Run `019fe1b3-af54-7a69-bd1d-0cd940842e41` completed after model turn
5 returned `finishReason: "length"` with no tool call.
- The replacement Daytona sandbox was healthy and mounted the correct
durable volume, isolating this from the sandbox recovery issue fixed in
#183 and #184.

## Verification

- `pnpm lint`
- `pnpm typecheck`
- `pnpm turbo build --force`
- `pnpm deadcode`
- `pnpm architecture:check`
- `pnpm turbo skills:build`
- production flow will be repeated after merge and exact-SHA Cloudflare
deployment

## How to review

1. Review the finish-reason schema in
`packages/agent-core/src/mastra/durable-agent-step.ts`.
2. Review the durable loop policy in
`apps/agent-worker/src/durable-objects/agent-run-workflow.ts`.
3. Confirm the shared schema is enforced by
`agent-run-workflow-runtime.ts` and the README contract matches the
implementation.